Background

Tool Dependency Installation

Arduino Create Agent performs installation and updates of the tool dependencies required for direct communication between the local machine and the target board.

It might be necessary to execute some sort of installation process in addition to placing the files from the tool archive on the user's hard drive. This capability is provided by a "post-install script" system. If a post-install script file (post_install.bat on Windows, post_install.sh other host operating systems) is found in the tool installation, Arduino Create Agent automatically executes it as part of the tool installation operation.

One of the tool dependencies is arduino:windows-drivers, which provides the Windows device drivers for the official Arduino boards. This tool contains a post-install script that installs the drivers from the tool archive. It is essential for this script to be executed as the presence of the driver files alone doesn't have any effect.

Go exec Package

From the Go 1.19 release, the behavior of the exec package was changed to make it more secure:

https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_directory

as of Go 1.19, this package will not resolve a program using an implicit or explicit path entry relative to the current directory. That is, if you run exec.LookPath("go"), it will not successfully return ./go on Unix nor .\go.exe on Windows, no matter how the path is configured. Instead, if the usual path algorithms would result in that answer, these functions return an error err satisfying errors.Is(err, ErrDot).

Problem

The code that executes the post-install script on Windows depended on the previous permissive behavior of the exec package. Ever since the version of Go used to build Arduino Create Agent was updated to 1.19 (#744), the script has not been executed.

This means Arduino Create Agent never installed the drivers from the arduino:windows-drivers tool on the machines who weren't using it before the 1.3.0 release.

The failure to execute the post-install script results in Arduino Create Agent attempting installation of the arduino:windows-drivers tool on every Arduino Cloud session. Even if the user is not impacted by the lack of drivers (either because it is not required for their board, or because they installed the drivers via some other mechanism), they will still be annoyed and confused by the frequent appearance of the "Installing drivers" dialog that is produced by Arduino Create Agent's post-install script execution code.

Demonstration

1. Start a build of Arduino Create Agent that does not contain the patch proposed here on a Windows machine.
2. Open the Arduino Create Agent "Debug Console".
3. Type the following command into the input field on the bottom of the Debug Console web page:

   downloadtool windows-drivers 1.8.0 arduino replace
   

   ⓘ This specific command is used to force an installation of the arduino:windows-drivers tool even if you already have the latest version installed.
4. Wait for the "Installing drivers" dialog to open.
5. Click the "Yes" button in the dialog.

🐛 Arduino Create Agent does not execute the post_install.bat batch file. You can see the cause in the Arduino Create Agent debug console:

{
  "DownloadStatus": "Error",
  "Msg": "exec: \"post_install.bat\": cannot run executable found relative to current directory"
}

Additional Context

I planned to add test coverage for github.com/arduino/arduino-create-agent/tools.Tools.installDrivers in order to avoid another such regression in the future. However, this is challenging to do for Windows due to the "Installing drivers" dialog. It seems it would be necessary to mock github.com/arduino/arduino-create-agent/tools.MessageBox, which would require selecting a mocking framework for the project.

I chose the approach that followed the system previously established in the code. A more elegant solution would be possible through the use of the the github.com/arduino/go-paths-helper module, which is already used elsewhere in the project. However, I feel that should be done as part of comprehensive migration to using the module for all path-related operations, which is out of scope for this PR.

I didn't have time to investigate it, but it is possible this will fix #856.

Originally reported at:

• https://forum.arduino.cc/t/initial-configuration-of-board-failing/1207822
• https://forum.arduino.cc/t/arduino-rp2040-cloud-setup/1219617